1. Field of the Invention
The present invention relates to a method, system, apparatus and an article of manufacture for accessing objects or more particularly, to a moniker for locating, activating and (or) initializing specific instances of program objects particularly in a large computer system environment such as a network and (or) particularly in an environment where the object is not registered, i.e., does not have a persistent state.
2. Related Information.
A moniker is a “smart” name which contains information that is used to link to instances of other objects. Monikers are Object Oriented Programming (OOP) programs and a better appreciation of them will be realized from the following general discussion
Object-Oriented Programming (OOP) is based on the ideology of using independent modular programs, called objects, as the building blocks for programming applications. The programming applications themselves may be considered composites of these objects. OOP prefers to think of a programming application as a client that invokes a particular object program, known as a class, as an instance of that object. The modularity of programming objects allows them to be instantiated, i.e., invoked, a plurality of times to create several run-time versions, i.e., objects, of the same object program. And therein lies the power of OOP—pieces of software (i.e., the object programs) are used, reused and interchanged between programming applications thereby avoiding redundancy, maintaining efficiency and freeing programmers to focus their attentions on the kernel, or core, of the programming application.
Windows NT™ (Windows New Technology) is a common operating system (O/S) from Microsoft™ that supports the OOP methodology. To support this methodology, Windows NT™ must provide a platform for executing OOP applications and accessing objects. In order to interface OOP application programs to the Windows NT™ operating platform, the O/S provides a set of functions, also referred to as methods, called the Application Programming Interface (API). The API is a language message format used by an application program to communicate with the Windows NT™ operating system (or other system program such as a database management system). APIs are implemented by writing function calls in the program that provide the linkage to a specific subroutine for execution.
Component Object Model (COM) is the component software architecture that the Windows NT™ operating system employs to access objects. Accessing objects in a common way on a system is paramount when one considers that objects, according to OOP methodology, are independent from the client. Thus, objects may be located anywhere on the system including program applications or persistent memory. To effect a common accessing scheme, COM defines a set structure for building program routines (objects) that can be called up and executed in the Windows™ environment. COM itself is written in an OOP language and objects therein are known as COM objects.
Programmers have evolved COM into a compound document technology known as Object Linking and Embedding (OLE) to handle the complex task accessing or embedding objects in applications or documents, called the container application. OLE, for example, allows an object such as a spreadsheet or video clip to be embedded into a document, called the container application. When the object is double clicked, the application that created it, called the server application, is launched in order to edit it. An object can be linked instead of embedded—in which case the container application does not physically hold the object, but provides a pointer to it. If a change is made to a linked object, all the documents that contain that same link are automatically updated the next time the user opens them. An application can be both client and server.
The present invention relates to accessing objects within the COM environment. In order to instantiate a COM class, the client must first grab hold of a pointer to a COM-compliant interface. The set of operations carried out to somehow retrieve a valid interface pointer to a live object is called binding. In the case where the client needs only a general instance of the class, this interface pointer is obtained by creating a new instance of the co-class through the well known CoCreateInstance( ) API provided by OLE, as demonstrated in the following code snippet:
IInterface* NewObject(clsid){HRESULT hr;IIntertace* pInterface = NULL;// Error handling omittedhr = CoCreateInstance(clsid, NULL, CSLCTX_ALL, IID_IInterface,(void**)&pInterface);if (SUCCEEDED(hr))      return pInterface;return NULL;
The function CoCreateInstance creates an instance of the identified class and receives a pointer to the IDispatch interface of that instance. The IDispatch interface allows for the invocation of methods that are bound to at run time.
The foregoing interface works well for instantiating objects. However, when the client needs to access an already-existing object (a specific instance), the CoCreateInstance function is not applicable. For example, in the case where an Excel™ application (client) links to a pre-stored Excel™ data file (specific instance), it will not do to instantiate a new object. Instantiating a new object creates a new version of that object—it does not access the specific instance.
Moreover, it is undesirable to employ the CoCreateInstance function because it requires the server to be actively involved in instantiating the relevant object. Recalling that the tenet of Object Oriented Programming is to establish independency between programs, it is unsatisfactory that the server be burdened with calling and passing parameters to the instantiation routine.
COM provides special programming objects called monikers that allow clients, such as an Excel™ application, to link specific instances of an object. In simplistic terms, a moniker is a smart name which stores that information which allows the client to locate and invoke the instance. In our Excel™ example, a call to the moniker that points to the Excel™ data file will automatically produce a pointer to the parent Excel™ application. In this case, the operating system will automatically launch the Excel™ application and link it to the Excel™ data file. The Excel™ application need not be concerned about the details of linking to the object.
Monikers, while useful, are limited because they operate within the COM environment. In particular, COM monikers call only those objects that are registered in the operating system. This is a problem because the objects themselves are responsible for registration. In the case where, for example, a peripheral element such as a PLC (Programmable Logic Controller) is connected to a personal computer (PC), the PLC has no conventional way in which to register itself with the operating system. In that case, the standard monikers are unable to provide a pointer to the clients of the operating system for linking to the PLC. This is particularly true for a PLC that is remotely connected.
Another problem is that monikers automatically instantiate the object whether or not the object is already running. In the PLC™ example, the moniker would cause the PLC to be automatically instantiated. This is very dangerous because it may cause an otherwise dormant PLC to come “alive” and activate machinery connected thereto. This could have disastrous results in a manufacturing environment.
There is needed a means by which already-running specific instances, particularly of the kind heretofore described, are linked to client applications that reside on an operating server particularly where the object has not registered itself with the operating system. It is important that any such means operate within the bounds of the ideology of maintaining independency between the servers and clients as proscribed by Object Oriented Programming.